Embodiments of the present invention relate to a method for routing data in a chipset comprising at least one host processor and a Radio Frequency Identification (RFID)-type contactless data send/receive interface.
Embodiments of the present invention also relate to a data send/receive circuit comprising an RFID-type contactless data send/receive interface, a controller, and at least one input/output port to link the data send/receive interface to a host processor.
Embodiments of the present invention relate particularly to the production of a Near Field Communication (NFC) chipset.
NFC technology is currently developed by an industrial consortium grouped under the name Forum NFC (http://www.nfc-forum.org). The NFC technology is derived from RFID technology and uses NFC readers having several operating modes, i.e., a “reader” Mode, a “card emulation” mode, and a “device” mode (also referred to as “device-to-device” mode). In the “reader” mode, the NFC reader operates like a conventional RFID reader to read- or write-access an RFID chip (chip card or contactless tag). The NFC reader emits a magnetic field, sends data by modulating the amplitude of the magnetic field, and receives data by load modulation and inductive coupling. In the “emulation” mode, described by the patent EP 1 327 222 in the name of the applicant, the NFC reader operates passively like a transponder to communicate with another reader and to be seen by the other reader as an RFID chip. The reader does not emit any magnetic field, receives data by demodulating a magnetic field emitted by the other reader, and sends data by modulating the impedance of its antenna circuit (load modulation). In the “device” mode, the reader must match with another reader in the same operating mode, and each reader alternately enters a passive state (without field emission) for receiving data and an active state (with field emission) for sending data.
In addition to these three operating modes (other operating modes could be designed in the future), an NFC reader can implement several contactless communication protocols and is for example capable of exchanging data according to the ISO 14443-A protocol, the ISO 14443-B protocol, the ISO 15693 protocol, or the like. Each protocol defines a frequency of emission of the magnetic field, a modulation method for modulating the amplitude of the magnetic field to send data in active mode, and a load modulation method by inductive coupling to send data in passive mode. Therefore, an NFC reader is a multimode and multi-protocol device. The applicant markets, for example, an NFC reader under the name “MicroRead”.
Due to its extended communication capacities, an NFC reader is intended to be integrated into portable devices such as cellular telephones or Personal Digital Assistants (PDAs). The result is the production of an NFC chipset of the type represented in FIG. 1, i.e., a chipset comprising an NFC reader (referenced “NFCR1”) and at least one first host processor HP1. “Host processor” means any integrated circuit comprising a microprocessor or a microcontroller that is connected to a port of the NFC reader. In many applications, the chipset also comprises a second host processor HP2. The first host processor HP1 is the main processor of the device in which the NFC reader is integrated while the second host processor HP2 is a secure circuit. The host processor HP1 is, for example, the baseband circuit (or radiotelephone circuit) of a mobile telephone and the host processor HP2 is, for example, a SIM card (i.e., the microcontroller present in a SIM card). Therefore, the resources of the NFC reader are made available to the two processors HP1, HP2 to enable the processors HP1, HP2 to manage contactless applications. Such applications are shown in FIG. 2, which illustrates a mobile telephone 30 equipped with the NFC chipset in FIG. 1. The following can be distinguished:
1) Applications of AP1 type: The NFC reader of the mobile telephone 30 is in “reader” mode to read or write to a contactless integrated circuit CLCT. The mobile telephone 30 is here used like an RFID reader. This type of application can be free of charge and consist, for example, in reading advertising data inserted into an advertisement of a bus shelter. The application can also be payable and consist for example in reading information reserved for subscribers. The program of the application AP1 is preferably held and executed by the processor HP1 if the service is free of charge, or will preferably be held and executed by the processor HP2 if it is payable, as it requires an identification of the subscriber. Thus, as shown in FIG. 1, an application AP1 can be processed by the processor HP1 or the processor HP2.
2) Applications of AP2 type: The NFC reader of the telephone 30 is in “card emulation” mode to be read by conventional RFID readers in payment or payable access control applications (payment machine, entrance to the subway, etc.). The mobile telephone 30 is then used like a chip card. The program of the application AP2 is preferably held and executed by the secure processor HP2, as represented in FIG. 1, as the access to the service requires an identification of the subscriber.
3) Applications of AP3 type: The NFC reader of the telephone 30 is in “device” mode and communicates with another device, such as a reader integrated into another mobile telephone 31 or a computer 32. This type of application is generally free of charge and enables data packets to be transferred from one device to another (particularly point-to-point file transfer). The program of the application AP3 is preferably held and executed by the non-secure processor HP1, as shown in FIG. 1, which has a computing power greater than the secure processor HP2, if the latter is a SIM card processor.
Thus, the production of an NFC chipset requires providing a routing of the data streams between each of the processors HP1, HP2 and the NFC reader (data sent via the contactless data transmission channel) and of the incoming data streams (data received via the contactless data transmission channel) between the NFC reader and each of the processors HP1, HP2. This poses a certain number of practical problems that will be understood with reference to FIGS. 3A and 3B.
FIG. 3A schematically represents the architecture of the NFC reader. The reader comprises a contactless data send/receive interface CLINT equipped with an antenna circuit ACT, hard-wire communication interfaces INT1, INT2 linked to the interface CLINT, and a controller NFCC. The interface INT1 is connected to the host processor HP1 and the interface INT2 connected to the host processor HP2, the assembly forming an NFC chipset (referred to as “CHIPSET”).
FIG. 3B represents the data streams that must be directed so that the resources of the contactless data send/receive interface CLINT can be used by each of the processors HP1, HP2. It is assumed for the sake of simplicity that the interface CLINT can send or receive data according to three protocols PT1, PT2, PT3 only, for example ISO 14443-A, ISO 14443-B, and ISO 15693, and has the three abovementioned operating modes M1, M2, M3 (“reader” mode, “emulation” mode, and “device” mode). Thus, four different types of data stream can be distinguished:
1) an outgoing data stream DT1out(Mi, PTi) transmitted from a source point P1 located in the processor HP1 to a destination point P3 located in the interface CLINT, then sent thereby in a contactless data transmission channel created according to a protocol PTi (PT1, PT2 or PT3) and an operating mode Mi (M1, M2 or M3);
2) an outgoing data stream DT2out(Mi, PTi) transmitted from a source point P2 located in the processor HP2 to a destination point P3 located in the interface CLINT, then sent thereby via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi;
3) an incoming data stream DT1in(Mi, PTi) received by the interface CLINT via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi, then sent by the interface CLINT from a source point P3 to a destination point P1 located in the processor HP1; and
4) an incoming data stream DT2in(Mi, PTi) received by the interface CLINT via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi, then sent by the interface CLINT from a source point P3 to a destination point P2 located in the processor HP2.
Since each outgoing data stream can be sent in three operating modes M1, M2, M3 and according to three protocols PT1, PT2, PT3, it follows that 9 different configurations are possible for each outgoing data stream (assuming that each mode Mi/protocol PTi combination is authorized). It is therefore not sufficient for one of the processors HP1 or HP2 to simply send to the interface CLINT the data to be transmitted. The processor must also specify, for each string of data sent, the mode/protocol Mi/PTi configuration to be used by the interface CLINT to transmit the data in a contactless data transmission channel.
To enable the routing of outgoing data while allowing the interface CLINT to be appropriately configured, it has been proposed to provide a “Host Controller Interface” (HCI) data transfer protocol of “universal” type, enabling any type of host processor to supply the interface CLINT with data to be transmitted, while specifying the configuration to be used (protocol PTi and operating mode Mi) to transmit the data in the contactless communication channel. Such an HCI protocol provides data frames, each comprising header fields and data fields. The header fields comprise the information required to control the interface CLINT, particularly fields specifying the starting and destination points of the data, the operating mode, and the protocol to be used by the interface CLINT.
Classic HCI protocol provides data frames having long and complex header fields, requiring a considerable processing time before the data is are processed. This is referred to as “overheading”, which means that excessively long frame headers overload the data streams and increase the data transmission time. These large header fields further require large buffers and high processing capacity.
It is therefore desirable to provide a method for routing data in an NFC chipset that is simple to implement and does not require any long header fields, while enabling the protocol and the operating mode parameters of the contactless data send/receive interface to be set.
Additionally, when incoming data is received, the contactless data send/receive interface CLINT and the controller NFCC do not necessarily know which is the intended host processor of the data. As a result, the data is sent to both processors, and it is up to the unintended processor to ignore the data.
The application WO 2004/029860 suggests a routing method that involves using, as means for routing incoming data, the Application Protocol Data Unit (APDU) field located in commands received via the contactless data transmission channel. However, as indicated at page 13 of said application, the method requires new protocols to be developed to implement the routing, which means that the external unit sending the data in the contactless data transmission channel must specify for which internal unit (which host processor) the data is intended.
In many applications, the external unit sending data is not designed to give routing indications specifying which is the processor receiving the data. Indeed, the routing is an internal problem linked to the fact that several processors of a same chipset share the same contactless data send/receive interface. It is therefore quite unlikely in the near future that a universal routing protocol will be integrated into devices that do not meet an NFC standard. For example, a conventional reader used for payment or control access sends authentication and/or secret code verification commands destined for contactless chip cards. Therefore, during an authentication, such a reader does not know whether it is addressing a real contactless card or an NFC chipset in “card emulation” mode. As a result, such a reader is not designed to send parameters enabling the application data it sends to be routed inside the chipset.